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DATA TRANSFER METHOD 

FIELD OF THE INVENTION 

The present invention relates to the field of digital data transfer 
5 methods, more particularly to the transfer of data in which normal digital data 
and encrypted digital data co-exist in the same data. 

BACKGROUND OF THE INVENTION 

One conventional data transfer method adopts the IEEE 13 94 standard 
io (IEEE: The Institute of Electrical and Electronics Engineers, Inc.). (Reference: 
IEEE Std 1394: 1995, High Performance Serial Bus.) In data transfer specified 
by the IEEE 1394 standard, there are two methods of communication. One is 
isochronous communication, which is suitable for transferring synchronous data 
such as digital video signals and digital audio signals. The other is asynchronous 
15 communication, which is suitable for transferring asynchronous data such as 
control signals. Both methods of communication are applicable on the IEEE 1394 
bus network. Isochronous communication is what is called Broadcast 
communication, and an isochronous packet output from one device coupled to the 
IEEE 1394 bus is receivable by all the other devices coupled to the same bus. On 
20 the other hand, asynchronous communication is applicable to both one-to-one 
communication and one-to-N broadcast communication. Each asynchronous 
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packet output from one device coupled to the bus contains an identifier specifying 
the device(s) to which that packet is addressed. If this identifier specifies a 
particular device, only the device specified by the identifier receives the 
asynchronous packet. If the identifier specifies broadcast, all the devices coupled 
5 to the same bus receive the asynchronous packet. 

At present, the IEC (International Electrotechnical Commission) is 
preparing to stipulate the IEC 1883 standard (hereafter referred to as AV 
protocol) for transferring digital audio signals and digital video signals or 
transmitting data between devices coupled to an IEEE 1394 bus, employing the 

10 data transfer method conforming to the IEEE 1394 standard. In the AV protocol, 
video and audio data is located in the isochronous packet as shown in Fig. 5 and 
transferred. The isochronous packet includes a CIP (Common Isochronous 
Packet) header. The CIP header carries information that includes the type of AV 
data, the identification number of the device which is sending the isochronous 

15 packet, and the like. 

Fig. 5 shows the format of the isochronous packet used in the AV 
protocol. The isochronous packet comprises an isochronous packet header 900, 
header CRC 901, isochronous payload 902, and data CRC 903. The isochronous 
packet header 900 contains a tag 907. The tag 907 shows that the isochronous 

2 o packet conforms to the AV protocol when its value is 1 . When the value of the 
tag 907 is 1, which means that the isochronous packet conforms to the AV 
protocol, the isochronous payload 902 has a CIP header 904 at its beginning. The 
CIP header 904 comprises a source ID 906 which identifies the device 
transmitting the isochronous packet. The CIP header 904 also comprises FMT 

25 908 and FDF 909 which specify the type of actual data 905 in the isochronous 



MAT-V07839 

-3- 

payload 902. Digital AV data is contained in the actual data 905, but the actual 
data 905 is not always contained in the isochronous pay load 902. Some packets 
may have an isochronous payload 902 which contains only the CIP header 904 
without the actual data 905. 
5 There is a group of commands called the AV/C Command Set for 

controlling devices in accordance with the AV protocol (Reference: 1394 
TRADE ASSOCIATION Specification for AV/C Digital Interface Command Set 
Version L0, September 13, 1996). These commands and their responses are 
, 3 transferred by means of asynchronous communication. 

,3 10 In the conventional data transfer method as described above, 

if 1 compatibility with conventional devices which are not designed for transferring 
:M an encrypted isochronous payload 902 cannot be secured when an encrypted 

r 3 isochronous packet, which contains the isochronous payload 902 which has been 

■J encrypted for copyright protection, is sent. More specifically, conventional 

ri; 15 devices are designed with the precondition that the CIP header 904 is normally 
positioned at the beginning of the isochronous payload 902. Accordingly, if the 
isochronous payload 902 is encrypted, conventional devices cannot correctly read 
out the encrypted CIP header 904, and decide that the isochronous packet does 
not conform to the AV protocol. A device receiving encrypted isochronous 
20 packets thus may not operate properly. In other words, such receiving devices 
cannot determine the type of data contained in the actual data 905, resulting in an 
inability to identify the device transmitting the isochronous packet. In addition, 
asynchronous communication such as queries to the sending device are disabled. 
Accordingly, normal receiving operations cannot be carried out. 
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Furthermore, if the isochronous packet output from the sending 
device is encrypted while the receiving device is receiving the data, some 
conventional devices may not be able to correctly read out the CIP header 904 as 
soon as encryption starts, resulting in inability to receive data properly. 
5 In order to send AV information encrypted for copyright protection 

from the sending device and decrypt the encrypted AV data by the authorized 
receiving device, the sending device needs to give decrypting information for 
decryption to the authorized receiving device. In the conventional data transfer 
method, however, the sending device may be required to execute extremely 

10 complicated procedures in order to specify the receiving device. More 
specifically, each isochronous packet contains the source ID 906 which is the 
identifier of the sending device, but these packets do not contain information that 
identifies which device is authorized to receive these packets. The sending device 
thus cannot check which device is receiving the isochronous packets during 

15 transmission of the isochronous packets. In order to find which of the devices 
coupled to the IEEE 1394 bus is receiving the data, the sending device may 
require to query the data receiving status of every device coupled to the same 
bus. This makes the procedures for giving key information for decryption 
extremely complicated. 

20 

SUMMARY OF THE INVENTION 

A data transfer method of the present invention satisfies the 
conventional communication standard even in the case of sending encrypted 
video and audio information via isochronous communication. In addition, the 
25 present invention offers a data transfer method which prevents erroneous 
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operation even if conventional receiving devices receive isochronous packets 
containing encrypted video and audio data. 

The present invention still further offers a data transfer method 
which significantly simplifies procedures for giving key information for 
5 decryption from a sending device to an authorized receiving device. 

In a data transfer method of the present invention, synchronous data 
transferred via isochronous communication contains i) encryption identification 
information which indicates encryption status of actual data and ii) actual data, 
and only the actual data is encrypted. 

10 To solve another problem in the conventional data transfer method, 

the encryption identification information which indicates encryption status of the 
actual data in the synchronous data is sent together with the actual data from the 
sending device, so that receiving device can detect that the actual data is 
encrypted based on this encryption identification information and requests 

15 decrypting information from the sending device in the data transfer method of the 
present invention. Then, the receiving device receiving the decrypting 
information sent from the sending device upon request decrypts the actual data 
using this decrypting information to complete data transfer. 

Also in the data transfer method of the present invention, the 

20 receiving device receiving synchronous data checks for the encryption 
identification information contained in the synchronous data. If the receiving 
device detects that the actual data is encrypted, the receiving device requests 
decrypting information for decrypting the actual data from the sending device. 
This request is made using a command in the AV/C set via asynchronous 

25 communication. At receiving this request, the sending device checks the packet 
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header of received command to identify the device making the request, i.e., the 
receiving device. The sending device then gives decrypting information to the 
identified receiving device using a command via asynchronous communication, 
enabling to realize the data transfer method with extremely simple procedures for 
giving decrypting information from the sending device to the receiving device. 

Moreover, in the data transfer method of the present invention, only 
the actual data in the synchronous data is encrypted, and the encryption 
identification information indicating the encryption status of the actual data is 
included in the synchronous data. This enables to transfer the CIP header without 
being encrypted, preventing erroneous operation when the conventional device 
receives such encrypted synchronous data. In other words, the present invention 
realizes a data transfer method which assures compatibility with the conventional 
data transfer method and eliminates the possibility of erroneous operation when 
the conventional receiving device receives encrypted synchronous data. 

Furthermore, the data transfer method of the present invention 
eliminates the possibility of erroneous operation of the receiving device receiving 
data when encryption of synchronous data starts while continuously receiving 
synchronous data from the sending device because the CIP header is not 
encrypted and transferred as it is. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a schematic view of a format of a CIP header in accordance 
with a preferred embodiment of the present invention. 
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Fig. 2 is a block diagram illustrating functions of sending and 
receiving devices in accordance with the preferred embodiment of the present 
invention. 

Fig. 3 A is a format of AKE status command in accordance with the 
preferred embodiment of the present invention. 

Fig. 3B is a format of AKE response to the AKE status command in 
accordance with the preferred embodiment of the present invention. 

Fig. 3C is a format of AKE control command in accordance with the 
preferred embodiment of the present invention. 

Fig. 4 is a schematic view illustrating procedures for transmitting an 
asynchronous packet between sending and receiving devices in accordance with 
the preferred embodiment of the present invention. 

Fig. 5 is a format of isochronous packet in a data transfer method of 
the prior art. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

A preferred embodiment of the present invention is described next 
with reference to the drawings. 

Fig. 1 shows a format of the pay load of an isochronous packet to be 
transferred in the preferred embodiment of the present invention. The preferred 
embodiment is one example of the transfer of a TSP (Transport Packet) in 
accordance with MPEG (the Moving Picture Expert Group) specifications. The 
ENC (hereafter referred to as encryption information) 910 indicates whether the 
actual data 905 is encrypted or not. 
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Fig. 2 shows the relation between sending and receiving devices in 
the preferred embodiment of the present invention. A sending device 110 and 
receiving device 128 are coupled via an IEEE 1394 bus (hereafter referred to as 
a 1394 bus) 111. 

First, the functions of each block in the sending device 110 are 

described. 

A signal source 100 outputs an MPEG transport packet TSP (not 
illustrated) in an 188 byte unit, which will be sent via the 1394 bus 111, to an 
encrypter 101. In other words, in the preferred embodiment, the signal source 
100 outputs data with a fixed length of 188 bytes. The encrypter 101 encrypts 
and outputs the TSP received from the signal source 100 using an encryption key 
109 provided by a key generator 106. In the preferred embodiment, the 
encryption key 109 is equivalent to the decrypting information. An output 
command 105 is a command from the key generator 106 to the encrypter 101. 
There are three types of commands: normal output, encrypted output, and empty 
output. If the encrypter 101 receives the output command 105 for normal output, 
the TSP received from the signal source 100 is output without modification, and 
registers the value 0 as the encrypting information 910. If the output command 
105 is for encrypted output, the encrypter 101 encrypts the TSP with the 
encryption key 109 received from the key generator 106, and registers the value 
1 as the encrypting information 910. If the output command 105 is for empty 
output, the encrypter 101 outputs an empty signal (not illustrated) every time it 
receives a TSP from the signal source 100, and registers the value 1 as the 
encrypting information 910. A source packet generator 102 adds a 4-byte source 
packet header to the 188-byte TSP received from the encrypter 101, and outputs 
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a 192-byte source packet (actual data 905). A CIP block generator 103 adds a 
CIP header 954 to the source packet received from the source packet generator 
102, and outputs an isochronous payload 952. Here, the CIP block generator 103 
places the encrypting information 910 received from the encrypter 101 in the CIP 
header 954. An isochronous packet generator 107 adds an isochronous packet 
header 900, header CRC 901, and data CRC 903 to the isochronous payload 952 
received from the CIP block generator 103, and outputs an isochronous packet. 
Since the content of the isochronous payload 952 is data that conforms to the AV 
protocol, the value of the tag 907 is set to 1. The key generator 106 sends the 
encryption key 109 to the receiving device 128 by communicating the 
asynchronous packet with the receiving device 128, as shown in Fig. 3, which is 
described later. The key generator 106 also outputs the encryption key 109 to the 
encrypter 101 as described above. 

A 1394 packet I/O controller 108 inputs and outputs isochronous and 
asynchronous packets between the 1394 bus 111 and sending device 110. More 
specifically, the 1394 packet I/O controller 108 outputs the isochronous packet 
received from the isochronous packet generator 107 and asynchronous packet 
received from the key generator 106 to the 1394 bus 111, and also outputs 
asynchronous packet received from the 1394 bus 111 to the key generator 106. 

Next, functions of each block of the receiving device 128 are 

described. 

A 1394 packet I/O controller 127 inputs and outputs isochronous and 
asynchronous packets between the 1394 bus 111 and receiving device 128. More 
specifically, the 1394 packet I/O controller 127 outputs the isochronous packet 
received from the 1394 bus 111 to a payload extractor 123, and outputs 
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asynchronous packet received from the 1394 bus 111 to a key generator 125. The 
1394 packet I/O controller 127 also outputs asynchronous packet received from 
the key generator 125 to the 1394 bus 111. 

The payload extractor 123 receives the isochronous packet, 
transmitted from the 1394 bus 111, from the 1394 packet I/O controller 127. 
When the value of the isochronous packet tag 907 is 1, the payload extractor 123 
determines that an isochronous payload 952 contains data conforming to the AV 
protocol, and outputs the isochronous payload 952 to an actual data extractor 
122. When received isochronous payload 952 contains the actual data 905, the 
actual data extractor 122 outputs the actual data 905 to a decrypter 121, after 
removing the CIP header 954 placed at the beginning of the isochronous payload 
952. The actual data extractor 122 also outputs the source ID 906 and encrypting 
information 910 extracted from the CIP header 954 to the key generator 125. 
The encrypting information 910 is also output to the decrypter 121. The key 
generator 125 receives an encryption key 126 as a result of exchanging 
asynchronous packet with the sending device 110 via asynchronous 
communication, which is described later, and outputs the encryption key 126 to 
the decrypter 121. When the value of the encrypting information 910 received 
from the actual data extractor 122 is 0, the decrypter 121 outputs the actual data 
905 received from the actual data extractor 122 to an AV generator 120 as it is. 
When the value of the encrypting information 910 is 1, the decrypter 121 
decrypts the actual data 905 using the encryption key 126 received from the key 
generator 125, and outputs decrypted actual data 905 to the AV generator 120. 

Next, the transmission of an asynchronous packet via the 
aforementioned asynchronous communication setup is described. 
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Figs. 3 A to 3C illustrate how the format of the asynchronous packet 
is transmitted by asynchronous communication. More specifically, Figs. 3A and 
3C show the command formats of the AKE commands (AKE: Authentication and 
Key Exchange) communicated between the key generators 106 and 125. Fig. 3B 
shows the response format. These commands and responses belong to the AV/C 
Command Set, and are communicated between the sending device 110 and 
receiving device 128 using the asynchronous communication. By communicating 
these commands and responses, the sending device 110 and receiving device 128 
exchange information required for the authentication of each other and 
encryption keys 109 and 126. The AKE commands comprise AKE control 
commands for requesting a target device to carry out a specific operation, and an 
AKE status commands for querying the status and capabilities of the target 
device. 

Fig. 3 A shows the format of the AKE status command. In the AKE 
status command, an operation code 208 indicates that this command is an AKE 
command. The value of the algorithm ID 200 is set at 0, with other values 
reserved for future extension. 

Fig. 3B shows the format of responses to the AKE status commands. 
This is a response sent back from the device receiving the AKE status command 
to the device issuing the AKE status command. There are multiple procedures for 
exchanging information for mutual authentication and transmission of encryption 
keys 109 and 126 between the sending device 110 and receiving device 128. In 
an algorithm field 201, the identifier for an information exchange procedure 
which the device returning an applicable response can execute is assigned in bits. 
In other words, the receiving device 128 exchanges several commands and 
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responses with the sending device 110 after an encrypted TSP is detected in line 
with the aforementioned procedures and before receiving the encryption keys 109 
and 126. There is more than one information exchange procedure for 
communicating these commands and responses. The device sending back the 
response designates the executable information exchange procedure by setting 1 
to an applicable bit in the algorithm field 201. Since the size of the algorithm 
field 201 is 16 bits, a maximum of 16 types of information exchange procedures 
can be indicated. The maximum data length 212 indicates the longest receivable 
data length in the form of bytes for exchanging AKE commands and responses. 

Fig. 3C shows the format of the AKE control commands. The 
algorithm field 201 in the AKE control commands set informs of an executed 
information exchange procedure when the value of the algorithm ID 200 is 0. 
Only one bit in the algorithm field 201 of the AKE control command and the 
response to AKE control commands is set at 1, and the other bits are 0. A bit 
having the value 1 indicates the information exchange procedure being used. A 
label 202 is used for identifying correspondence between AKE control 
commands. For example, let's say a certain information exchange procedure 
specifies that the device receiving an AKE control command needs to return a 
different AKE control command corresponding to the AKE control command 
received when the AKE control command is sent from one device to another. In 
this case, the label 202 inserted in the returned AKE control command will have 
the same value as the label 202 inserted in the first AKE control command 
received, in order to clarify the correlation between both AKE control 
commands. In step No. 203, a serial number from 1 is given to each AKE 
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control command in the sequence of communication in the information exchange 
procedure. 

A subfunction 299 takes the values shown in Table 1, and the 
meaning of each AKE command is determined by these values. 



Table 1 



Subfunction 


Value 


Make-response 


0016 


Verify-me 


0116 


Create-key- 


1016 


mformauon Reconstruct-key 


1116 


Exchange 


2016 



If the subfunction 299 is the make-response, this AKE control 
command challenges the authentication of the device receiving this command. 

io Here, the data 207 contains authentication challenge data expressed as random 
numbers to authenticate the receiving device. The device receiving this command 
returns an AKE control command whose subfunction 299 is set to verify-me. 

When returning the AKE control command, the data stored in the 
data 207 is the authentication response data which is a result of a predetermined 

15 operation with respect to the authentication challenge data in the received data 
207. The key information used for this operation is a key given only to an 
authorized device in advance. Whether the device executing the operation is an 
authorized device or not can be determined by checking the returned 
authentication response data. 

20 If the subfunction 299 is the create-key-information, this AKE 

control command requests the encryption key 109 to the device receiving this 
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command. The device receiving this AKE control command returns the AKE 
control command whose subfunction 299 is set to reconstruct-key. At this point, 
the encrypted encryption key 109 is stored in the data 207 and returned. 

If the subfunction 299 is the exchange, this AKE control command 
requests the exchange of key information between devices sending and receiving 
the command. This key information is stored in the data 207 and transferred for 
indirect authentication between devices or the creation of a common key. 

Values of the subfunction other than those specified in Table 1 are 
reserved for future extension. The channel No. 204 indicates the channel number 
for isochronous communication between the sending device 110 and receiving 
device 128. This channel No. 204 is valid only when the subfunction 299 is set to 
the create-key-information or reconstruct-key. In other cases, this value will be 
set to FF in hexadecimal format. Block No. 205 and total block No. 206 are used 
when data which should be handled by the AKE control command cannot be sent 
by one AKE command. In this case, applicable data is divided into blocks, and 
transferred in several transmissions. The total block No. 206 indicates the 
number of divided blocks in applicable data. The block No. 205 indicates the 
number of each block in the data 207. The data length 209 indicates the valid 
data length, as bytes, in the data 207. The data 207 is data exchanged by the 
AKE control command. The device receiving the AKE control command returns 
a response to that specific AKE control command. The format and value of the 
response are the same as those of the received AKE control command. The only 
detail which differs is that the response does not contain the data 207. 

Fig. 4 shows a time sequence example of AV/C commands which 
are exchanged between the sending device 1 10 and receiving device 128 before 
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sending the encryption keys 109 and 126 from the sending device 110 to 
receiving device 128. First, operations of both devices before exchanging AV/C 
commands shown in Fig. 4 are briefly described. 

An initial condition is that non-encrypted TSP is sent from the 
sending device 110. The TSP output from the signal source 100 is input to the 
encrypter 101. Since the output command 105 is set to the normal output, the 
encrypter 101 outputs TSP as it is without encryption to the source packet 
generator 102, and registers the value 0 as the encrypting information 910. The 
source packet generator 102 adds 4-byte source packet header to the TSP 
received, and outputs it to the CIP block generator 103. The CIP block generator 
103 adds 8-byte CIP header 954, and outputs it as isochronous payload 952 to the 
isochronous packet generator 107. Here, the encrypting information 910 
contained in the CIP header 954 is 0 which is input from the encrypter 101. The 
isochronous packet generator 107 adds the isochronous packet header 900, 
header CRC 901, and data CRC 903 to the received isochronous payload 952 to 
create the isochronous packet. This isochronous packet is output to the 1394 bus 
111 by the 1394 packet I/O controller 108. Since the applicable isochronous 
packet conforms to the AV protocol, the tag 907 in the isochronous packet 
header 900 is set to 1 . 

When the TSP output from the signal source 100 is changed, which 
means that AV information changes from that unprotected AV information to 
copy-protected AV information, the key generator 106 detects this change, and 
changes the output command 105 from the normal output to empty output. At the 
same time, the encryption key 109 for encrypting TSP is given to the encrypter 
101. 
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When the output command 105 is for empty output, the encrypter 
101 outputs an empty signal to the source packet generator 102 every time it 
receives a TSP from the signal source 100, and registers the value 1 as the 
encrypting information 910. At receiving the empty signal from the encrypter 
5 101, the source packet generator 102 transmits the received empty signal as it is 
to the CIP block generator 103 without adding the source packet header. When 
the CIP block generator 103 receives the empty signal, it outputs only the CIP 
header 954 to the isochronous packet generator 107. Here, the encrypting 
information 910 in the CIP header 954 uses the value 1 output from the encrypter 

10 101. The isochronous packet generator 107 creates an isochronous packet as the 
isochronous payload 952 using the CIP header 954 received from the CIP block 
generator 103, and outputs it to the 1394 packet I/O controller 108. Since this 
isochronous packet conforms to the AV protocol, the value of the tag 907 is set 
to 1 . The 1394 packet I/O controller 108 outputs received isochronous packet to 

15 the 1394 bus 111. This isochronous packet is continuously output, and the 
isochronous packet only containing the CIP header 954 in this isochronous 
payload 952 is continuously output to the 1394 bus 111. The receiving device 
128 receiving this isochronous packet checks its tag 907 by the 1394 packet I/O 
controller 127, detects that the isochronous packet conforms to the AV protocol, 

20 and then outputs this isochronous packet to the payload extractor 123. The 
payload extractor 123 extracts the isochronous payload 952 from received 
isochronous packet, and outputs it to the actual data extractor 122. The actual 
data extractor 122 outputs the encrypting information 910 and source ID 906 in 
the CIP header 954 to the key generator 125. After the key generator 125 detects 

25 that the value of the encrypting information 910 is 1, the key generator 125 
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learns from the source ID 906 that device outputting the isochronous packet is 
the sending device 110. Then, the key generator 125 finally goes onto a process 
for requesting the encryption keys 109 and 126 using the A/C commands, as 
shown in Fig. 4. 

5 In Fig. 4, the AKE status command 300 is first sent from the 

receiving device 128 to sending device 110. This enables the receiving device 
128 to query information exchange procedure that can be used by the sending 
device 110. Replying to this query, the sending device 110 returns the AKE 
response 301 to the receiving device 128. Information exchange procedure which 

10 the sending device 110 can execute is assigned in bits in the algorithm field 201 
of the AKE response 301. This allows the receiving device 128 to learn which 
information exchange procedures can be executed by the sending device 110. For 
example, if the sending device 110 can execute the second and sixth information 
exchange procedures, binary indication in the algorithm field 201 of the AKE 

15 response 301 will be 0000000000100010. 

The receiving device 128 receiving the AKE response 301 selects 
one optimal procedure from information exchange procedures that both sending 
device 110 and receiving device can execute. Then, AV/C commands are 
exchanged according to the selected exchange procedure. Let's say the receiving 

20 device 128 can execute the second and eighth information exchange procedures. 
Then, the information exchange procedure which can be executed by both 
sending device 110 and receiving device 128 is only the second procedure. 
Accordingly, the rest of authentication and information exchange are executed 
using the second procedure. In the AKE control command in this procedure, the 

25 value of algorithm ID 200 will be 0 and the value of the algorithm field 201 will 
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be 0000000000000010 in binary indication. The information exchange procedure 
specifies not only the sequence of exchanging a range of AKE control commands 
but also a format and processing method of the data 207 sent by each AKE 
control command. 

5 In accordance with the second information exchange procedure, the 

key generator 125 sends the make-response command 302 to the sending device 
110. In the data 207 of this make-response command 302, two random numbers 
RRa and RRb generated by the key generator 125 are encrypted, and the 
algorithm field 201 contains identification information indicating the use of the 

io second procedure. The key used for encryption is a common secret key given to 
both authorized sending device and receiving device in advance. The key 
generator 106 receiving the make-response command 302 checks the algorithm 
field 201 of the received make-response command 302, and learns to use the 
second procedure for the rest of the authentication and information exchange. 

15 Since the key generator 106 can execute the second procedure, the key generator 
106 knows that the data 207 of the make-response command 302 sent in 
accordance with this second procedure contains two random numbers encrypted 
by this secret key. After taking out two random numbers RRa and RRb from the 
data 207 using this secret key, the key generator 106 returns a response 303 to 

20 inform that a response can be generated. Then, the key generator 106 stores one 
of the random numbers RRa taken out in the data 207, and sends the verify-me 
command 304 to the receiving device 128. This is the response requested by the 
previous make-response command 302. Hereafter, the algorithm field 201 of 
each AKE command exchanged between the sending device 110 and receiving 
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device 128 always contain the identification information indicating the second 
procedure. 

The key generator 125 receiving the verify-me command 304 
confirms that RRa in the data 207 conforms to the random number RRa 
generated by itself, and then returns a response 305 to the verify-me command 
304 to inform that verification has completed successfully. The key generator 
125 then finally authenticates that the sending device 110 is an authorized 
sending device. 

The sending device 110 then use the make-response command 306 
and verify-me command 308 in accordance with the procedures after the make- 
response command 302 described above to confirm that the receiving device 128 
is an authorized receiving device. However, the random number used here is 
RTa and RTb, and the random number sent back by the verify-me command 308 
is RTb. 

Now that both sending device 110 and receiving device 128 know the 
random numbers RRb and RTb, and have confirmed that both are authorized 
devices, the key generator 106 and key generator 125 separately generates a 
temporary key (not illustrated) from RRb and RTb using a common operation 
method specified by the second procedure. These temporary keys are a common 
key only between the sending device 110 and receiving device 128. 

Next, the key generator 125 sends the create-key-information 
command 310 to the sending device 110. A channel number of the isochronous 
packet that the receiving device 128 is currently receiving is stored in the channel 
No. 204 of the create-key-information command 310. The key generator 106 
receiving this create-key-information command 310 encrypts the encryption key 
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109 to be used for encrypting TSP with the aforementioned temporary key, and 
then returns a response 311 to inform that the create-key-information command 
310 has completed successfully. Then, the key generator 106 sends the 
reconstruct-key command 312 which stores the encryption key 109 encrypted by 
the temporary key in its data 207 to the receiving device 128. The key generator 
125 uses the temporary key to decrypt the data 207 of the reconstruct-key 
command 312 received, and obtains the encryption key 126. Then, the key 
generator 125 returns a response 313 to inform that the reconstruct-key command 
312 has completed successfully. Since the encryption keys 109 and 126 are 
encrypted and decrypted using the same temporary key, they are the same keys. 
The encryption key 126 is output from the key generator 125 to the decry pter 
121. This completes the procedure for granting decrypting information. 

The key generator 106 which has sent the reconstruct key command 
312 outputs the output command 105 for encrypted output to the encrypter 101. 
The encrypter 101 receiving this command encrypts TSP received from the 
signal source 100 by the encryption key 109, and starts to output it to the source 
packet generator 102. This enables the sending device 110 to send the 
isochronous packet containing TSP encrypted by the encryption key 109 in its 
isochronous pay load 952 on the 1394 bus 111. This isochronous packet received 
by the receiving device 128 is decrypted by the decrypter 121 using the 
encryption key 126 as described above, and outputs the decrypted packet to the 
AV generator 120. 

In the above series of AKE control commands, each set of the make- 
response command 302 and verify-me command 304; make-response command 
306 and verify-me command 308; and create-key-information command 310 and 
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reconstruct-key command 312, respectively has the same label 202. The make- 
response command 302, verify-me command 304, make-response command 306, 
verify-me command 308, create-key-information command 310, and reconstruct- 
key command 312 also have values 1, 2, 3, 4, 5, and 6 in the step No. 203 
respectively. 

If the actual data in the isochronous packet output from the sending 
device 110 changes from encrypted actual data to non-encrypted actual data, the 
decrypter 121 detects the change in the encrypting information 910, stops 
decryption, and outputs the data received from the actual data extractor 122 as it 
is to the AV generator 120. 

If a bus reset occurs in the 1394 bus 111 after the aforementioned 
processes shown in Fig. 4 starts, the procedures after and make-response 
command 302 need to be repeated. 

As described above, in the preferred embodiment of the present 
invention, the sending device sends encrypting information which indicates the 
encryption status of the actual data in the isochronous packet together with the 
actual data. This enables the receiving device receiving the isochronous packet to 
make a request to the sending device for an encryption key for decrypting the 
actual data if the receiving device detects, by checking the encrypting 
information in the isochronous packet, that the actual data is encrypted. The 
sending device receiving the request then gives the encryption key to the 
receiving device. Accordingly, the data transfer method of the present invention 
offers extremely simple procedures for giving the encryption key for decryption 
from the sending device to receiving device. 
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Moreover, in the preferred embodiment of the present invention, the 
isochronous packet transferred via isochronous communication contains i) 
encrypting information indicating the encryption status of the actual data and ii) 
actual data, but only the actual data is encrypted for data transfer. This makes 
possible a data transfer method which has no risk of erroneous operation when a 
conventional receiving device receives encrypted actual data while maintaining 
compatibility with the conventional data transfer method. 

Furthermore, in the preferred embodiment of the present invention, 
the CIP header remains non-encrypted for transfer even if encryption of 
synchronous data starts while the receiving device is continuously receiving 
synchronous data sent by the sending device. This enables a data transfer method 
which eliminates the possibility of erroneous operation of the receiving device 
receiving the data. 

In the preferred embodiment, once encryption by the encryption key 
starts, actual data in all transfer units is encrypted and sent. However, it is not 
necessary to encrypt all units of data to be transferred. For example, even if both 
encrypted transfer units and non-encrypted transfer units are sent alternately, the 
receiving device can correctly decrypt the data because encrypting information is 
included in the CIP header, thus achieving the same effect. In addition, it is 
apparent that the same effect is also achievable even if the receiving device 
specifies a percentage of encrypted transfer units to the sending device. The size 
of the MPEG source packet is 192 bytes, with more than one source packet 
stored in one isochronous payload in the case of the high data rate transfer of 
MPEG (12 Mbps minimum). Naturally, however, it is not possible to have both 
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encrypted source packet and non-encrypted source packet in the same 
isochronous pay load. 

In the preferred embodiment, all actual data is encrypted using the 
encryption key. However, it is not necessary to encrypt all pieces of data. For 
5 example, the same effect is achievable by encrypting the first half of the actual 
data, or encrypting the first and third quarters of the actual data. In this case, the 
receiving device can decrypt appropriately, if, when sending the data, 
information is inserted to indicate encrypted portions and their percentage in the 
CIP header. The same effect is also achievable by inserting in the CIP header 

10 encrypting information announcing whether the actual data is encrypted or not. 
The receiving device queries the sending device via asynchronous communication 
about which part of the actual data is encrypted and to what level, when the 
receiving device detects encryption by checking the CIP header. The same effect 
is also achievable in this case even when the receiving device specifies the 

15 encryption area and percentage to the sending device via asynchronous 
communication. If only the confidential portion in the actual data is encrypted, 
the burden for encryption and decryption is reduced, and at the same time, a 
sufficient effect of encryption may be achieved. 

In the preferred embodiment, the isochronous packet containing only 

2 0 the CIP header without actual data is transferred until the completion of mutual 
authentication between the sending and receiving devices. However, the same 
effect is achievable even when an isochronous packet containing encrypted actual 
data is output from the start, and not the isochronous packet containing only the 
CIP header. 
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In the preferred embodiment, procedures for transferring the AKE 
control commands between sending and receiving devices are determined by 
mutual negotiation. However, if the receiving device features only one 
executable procedure, the same effect is achievable by starting to transfer 
5 commands immediately, without executing this negotiation procedure, using only 
the executable procedure. In this case, it may be preferable to specify in advance 
a basic minimum of executable procedures for all authorized devices. 

In this preferred embodiment, direct authentication is implemented 
between the sending and receiving devices, following which decrypting 

10 information is transferred using a secret key. However, the means for 
transferring authentication and decrypting information is not limited to this 
procedure. For example, a public key may be used for mutual indirect 
authentication and the creation of a temporary key. Decrypting information may 
then be transmitted using this temporary key. Such procedures are briefly 

15 described below. 

The sending and receiving device stores the key information 
necessary for mutual indirect authentication in the data 207 of the AKE control 
commands, and send this information to each other in line with a procedure 
determined by mutual negotiation. Here, the subfunction 299 is set to the 

20 exchange. This enables both sending and receiving devices to share the same 
temporary key if they are both authorized devices. Decrypting information is 
then transferred using the create-key-information command and reconstruct-key 
command in accordance with the same procedures as those described in the 
preferred embodiment. 
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In the preferred embodiment, the procedure for transferring AKE 
control commands exchanged between sending and receiving devices is 
determined by mutual negotiation. If the types of procedures executable by the 
sending device are known in advance, the same effect is achievable by having the 
5 receiving device transfer commands using a procedure executable by the sending 
device without first executing this negotiation procedure. 

In the preferred embodiment, procedures for transferring AKE 
control commands exchanged between sending and receiving devices are 
P determined by mutual negotiation. However, the method for determining transfer 
-P 10 procedures is not limited to this one. More specifically, if priority is given in 
advance to each of several transfer procedures, the receiving device may start to 
W transfer using the procedure given the highest priority which is executable by 

itself. If the sending device cannot execute that procedure, the receiving device 
M tries to transfer data by going down the list of procedures in order of priority 

i : U 15 until a procedure that is executable by both the sending and receiving device is 
Q found. The AKE control commands are then transferred using this procedure to 
achieve the same effect. 

In the preferred embodiment, the sending device encrypts decrypting 
information which is used for decrypting actual data before transferring it to the 
2 0 receiving device. However, the way the receiving device obtains decrypting 
information is not limited to this procedure. In other words, the sending device 
may provide the receiving device sufficient information for obtaining decrypting 
information, without transferring encrypted decrypting information, and the 
receiving device may obtain decrypting information indirectly from this 
25 information. More specifically, the sending device transfers only the type of hash 
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function to the receiving device, and the receiving device obtains decrypting 
information using the received type of hash function to achieve the same effect. 

The preferred embodiment described above comprises an example of 
the AKE command format. However, the AKE command format is not limited to 
this one. In other words, the AKE command format indicated in this embodiment 
is just one example of how the preferred embodiment may be realized. The same 
effect is achievable by using commands in a different format. 

Industrial applicability 

As described above, the present invention has the significant effect 
of realizing a data transfer method using extremely simple procedures for passing 
key information for decryption from the sending device to the receiving device. 
Encryption identification information indicating the encryption status of actual 
data in synchronous data is sent together with actual data. The receiving device 
receiving the synchronous data checks the encryption identification information 
in the synchronous data, and if it detects that the actual data is encrypted, the 
receiving device requests the sending device for decrypting information for 
decrypting the encrypted data. The sending device receiving this request gives 
the decrypting information to the receiving device. 

The present invention has another significant effect of realizing a 
data transfer method which eliminates the possibility of erroneous operation of 
the receiving device even if conventional receiving device receives encrypted 
synchronous data, while maintaining compatibility with a conventional data 
transfer method. Synchronous data transferred through synchronous 
communication contains i) encryption identification information indicating 
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encryption status of the actual data and ii) actual data, but only the actual data is 
encrypted for data transfer. 

The present invention has still another significant effect of realizing a 
data transfer method which eliminates the possibility of erroneous operation of 
the receiving device even if encryption of synchronous data starts while the 
receiving device continuously receives synchronous data sent from the sending 
device. Synchronous data transferred through synchronous communication 
contains i) encryption identification information indicating encryption status of 
the actual data and ii) actual data, but only the actual data is encrypted for data 
transfer. This enables to transfer the CIP header as it is without being encrypted. 

The present invention has still another significant effect of realizing a 
data transfer method which always executes the most suitable procedure even 
when new and conventional devices share the same network. A procedure for 
transferring and receiving both authentication and decrypting information with 
good future extendibility are achievable by selecting a procedure for providing 
authentication information and decrypting information exchanged between the 
sending and receiving devices by negotiation between the sending and receiving 
devices. In other words, even if a new authentication method or decrypting 
information become available in the future, the most suitable procedure will 
remain selectable by negotiation between devices even if a device which can use 
the new procedure and a device which can use only conventional procedures 
share the same network, as long as the new device is back-compatible with older 
procedures. 

The present invention has still another significant effect of realizing 
decryption even if software which has a low encryption/decryption processing 
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speed is used. The present invention allows the relative proportion of encrypted 
actual data and non-encrypted actual data to be varied. Accordingly, even if the 
receiving device has no exclusive hardware for high-speed data decryption, 
software can be used instead. More specifically, even if the receiving device has 
no hardware for decryption like PC, rapid processing is made possible by 
reducing the proportion of encrypted data in the file and thus shortening the time 
required for the decryption process. 

The present invention has still another significant effect of realizing a 
data transfer method which uses the limited bus transfer band efficiently and 
significantly reduces the risk of unauthorized device receiving readable data. 
Unless the sending and receiving devices mutually authenticate that both are 
authorized devices, isochronous packets without actual data are output. 
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ABSTRACT OF THE DISCLOSURE 

A data transfer method which eliminates erroneous operation of 
conventional devices not supporting encryption when copy-protected AV 
information is encrypted and sent on an IEEE 1394 bus. Synchronous data 
transferred through isochronous communication contains i) encryption 
identification information for indicating encryption of actual data and ii) actual 
data. Only the actual data is encrypted. Encryption identification information 
indicating encryption of actual data in synchronous data is sent together with 
actual data from the sending device. A receiving device detecting encryption of 
actual data from this encryption identification information requests decrypting 
information from the sending device. The receiving device decrypts the actual 
data using decrypting information received from the sending device according to 
this request. 
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Please enter the substitute specification as attached hereto. Also 
enclosed is marked-up copy of the substitute specification showing additions 
and deletions. 

IN THE CLAIMS : 

Please cancel claims 12 through 15. 

Please amend the claims as follows: 

1 1. (Amended) A method for transferring data on a bus 

2 system [in which] using both isochronous communication and asynchronous 

3 communication [are employed]; said isochronous communication is for any 

4 device on the bus to receive synchronous data; said asynchronous 

5 communication is for a predetermined device to receive asynchronous data; 

6 said synchronous data [may] capable of containing actual data[;] and [said 

7 synchronous data also contains] encryption identification information [at an 

8 area other than said actual data; said encryption identification information 

9 indicates the status of encryption of said] indicating encrypted actual data; 

10 and encrypted actual data is decrypted using decrypting information obtained 
n through the following steps: 

12 a) [a receiving device] receiving said synchronous data [makes 

B a] at a receiving device, and said receiving device via said asynchronous 

14 communication requesting [for] decrypting information [of] for said actual 

15 data [to] from a sending device sending said synchronous data [via said 
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16 asynchronous communication], if said encryption identification [information 

17 indicates that said] indicates encrypted actual data [is encrypted]; 

18 b) [said sending device] receiving said request [sends] at said 

19 sending device and said sending device sending one of: 

20 i) encrypted decrypting information of said actual data; and 

21 ii) [data required for obtaining said] decrypting information data 

22 for obtaining said decrypting information, 

23 to said receiving device via said asynchronous communication; 

24 and 

25 c) [said receiving device executes] executing at said receiving 

26 device one of: 

27 i) [taking out] extracting said decrypting information from said 

28 encrypted decrypting information [when said receiving device receives said 

29 encrypted decrypting information]; and 

30 ii) obtaining said decrypting information using said [data for 

31 obtaining said] decrypting information data [when said receiving device 

32 receives said data for obtaining decrypting information]. 

1 2. (Amended) The method for transferring data as defined 

2 in Claim 1, wherein a plurality of [types of] procedures are available between 

3 the steps of detecting [encryption of said] encrypted actual data and obtaining 
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4 said decrypting information by said receiving device receiving said 

5 synchronous data; and said receiving device executes the [next] following 

6 steps for obtaining said decrypting information before requesting said 

7 decrypting information: 

8 i) querying said sending device of types of procedures 

9 executable by said sending device before requesting said decrypting 

10 information ; 

1 1 ii) selecting a procedure from those executable by both said 

12 sending device and receiving device; and 

13 iii) obtaining said decrypting information in accordance with 

14 said selected procedure. 

1 3. (Amended) The method for transferring data as defined 

2 in Claim 2, wherein [said] a procedure is selected in accordance with a 

3 predetermined priority when there are a plurality of procedures executable by 

4 both of said sending device and said receiving device. 

1 4. (Amended) The method for transferring data as defined 

2 in Claim 1, wherein a plurality of [types of] procedures are available between 

3 the steps of detecting [encryption of said] encrypted actual data and obtaining 

4 [of] said decrypting information by said receiving device receiving said 

5 synchronous data; and said receiving device executes the [next] following 

6 steps for obtaining said decrypting information: 
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7 i) starting [said] a procedure selected from said plurality of 

8 [types of] procedures in accordance with a predetermined priority; 

9 ii) re-selecting [one of] said procedures one-by-one until [said] a 

10 procedure executable by said sending device is found [when the procedure 
n selected by said receiving device is not executable by said sending device]; 

12 and 

13 iii) obtaining said decrypting information in accordance with the 

14 selected procedure [when a procedure] executable by said sending device [is 
is found]. 

1 5. (Amended) The method for transferring data as defined 

2 in [one of] Claim[s] 2 [to 4], wherein said asynchronous data transmitted 

3 between said sending device and said receiving device in accordance with 

4 said selected procedure contains an identifier for indicating the type of said 

5 procedure executed. 



1 6. (Amended) The method for transferring data as defined 

2 in one of Claims 1 to 5 , 16 and 17 , wherein said receiving device 

3 authenticates whether said sending device is an authorized sending device 

4 before making a request for said decrypting information. 

1 7. (Amended) The method for transferring data as defined 

2 in one of Claims 1 to 5 , 16 and 17 , wherein said sending device receiving a 

3 request for said decrypting information authenticates that said receiving 
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device is an authorized receiving device before sending encrypted decrypting 
information of said actual data [after confirming]. 

8. (Amended) The method for transferring data as defined 
in one of Claims 1 to 5 , 16 and 17 , wherein said sending device and said 
receiving device [mutually] are authenticated [that both are] as authorized 
[sending] devices [and receiving device] before said receiving device makes a 
request for said decrypting information. 

9. (Amended) The method for transferring data as defined 
in one of Claims 1 to 5, 16 and 17 [8], wherein the [next] following steps are 
executed before said receiving device makes a request for said decrypting 
information: 

i) said receiving device [sends] sending information required by 
said sending device at least for [creating] establishing a common key [to] 
with said sending device; and 

ii) said sending device [sends] sending information required by 
said receiving device at least for [creating] establishing said common key [to] 
with said receiving device; 

and [then] said sending device [encrypts] encrypting said 
decrypting information using said common key and [sends] sending said 
encrypted decrypting information; and said receiving device [takes out] 
extracting said decrypting information from said encrypted decrypting 
information received using said [common] encryption key. 
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1 11. (Amended) The method for transferring data as defined 

2 in one of Claims 1 to 5 , 16 and 17 , wherein said sending device [has] 

3 includes a signal source [of] for said actual data [inside] and determines 

4 encryption of [each of] said actual data in a fixed length unit which is output 

5 from said signal source; and said sending device places encrypted actual data 

6 and non-encrypted actual data in different output units of said synchronous 

7 communication, and then outputs them to said bus system. 

Please add new claims 16 through 20. 

1 16. (Newly Added) The method for transferring data as 

2 defined in Claim 3, wherein said asynchronous data transmitted between said 

3 sending device and said receiving device in accordance with said selected 

4 procedure contains an identifier for indicating the type of said procedure 

5 executed. 

1 17. (Newly Added) The method for transferring data as 

2 defined in Claim 4, wherein said asynchronous data transmitted between said 

3 sending device and said receiving device in accordance with said selected 

4 procedure contains an identifier for indicating the type of said procedure 

5 executed. 

1 18. (Newly Added) The method for transferring data as 

2 defined in Claims 1 to 5, 16 and 17, wherein said receiving device 
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authenticates whether said sending device is an authorized sending device 
before making a request for said decrypting information. 

19. (Newly Added) The method for transferring data as 
defined in Claim 10, wherein the following steps are executed before said 
receiving device makes a request for said decrypting information: 

i) said receiving device sending information required by said 
sending device at least for establishing a common key with said sending 
device; and 

ii) said sending device sending information required by said 
receiving device at least for establishing said common key with said receiving 
device; 

and said sending device encrypting said decrypting information 
using said common key and sending said encrypted decrypting information; 
and said receiving device extracting said decrypting information from said 
encrypted decrypting information received using said common encryption 
key. 

20. (Newly Added) The method for transferring data as 
defined in Claim 11, wherein the following steps are executed before said 
receiving device makes a request for said decrypting information: 

i) said receiving device sending information required by said 
sending device at least for establishing a common key with said sending 
device; and 
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7 ii) said sending device sending information required by said 

8 receiving device at least for establishing said common key with said receiving 

9 device; 

10 and said sending device encrypting said decrypting information 

n using said common key and sending said encrypted decrypting information; 

12 and said receiving device extracting said decrypting information from said 

13 encrypted decrypting information received using said common encryption 

14 key. 

Resentfully submitted, 
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DATA TRANSFER METHOD 



FIELD OF THE INVENTION 

The present invention relates to the field of digital data transfer methods, 
5 more particularly to the transfer of data in which normal digital data and encrypted digital 
data co-exist in the same data. 

BACKGROUND OF THE INVENTION 

One conventional data transfer method adopts the IEEE1394 standard 

10 (IEEE: The Institute of Electrical and Electronics Engineers, Inc.). (Reference: IEEE Std 
1394: 1995, High Performance Serial Bus.) In data transfer specified by the IEEE 1394 
standard, there are two methods of communication. One is isochronous communication, 
which is suitable for transferring synchronous data such as digital video signals and 
digital audio signals. The other is asynchronous communication, which is suitable for 

15 transferring asynchronous data such as control signals. Both methods of communication 
are applicable on the IEEE 1394 bus network. Isochronous communication is what is 
called "Broadcast communication, and an isochronous packet output from one device 
coupled to the IEEE 1394 bus is receivable by all the other devices coupled to the same 
bus. On the other hand, asynchronous communication is applicable to both one-to-one 

2 0 communication and one-to-N broadcast communication. Each asynchronous packet output 
from one device coupled to the bus contains an identifier specifying the device(s) to 
which that packet is addressed. If this identifier specifies a particular device, only the 
device specified by the identifier receives the asynchronous packet. If the identifier 
specifies broadcast, all the devices coupled to the same bus receive the asynchronous 

25 packet. 

At present, the IEC (International Electrotechnical Commission) is 
preparing to stipulate the IEC 1883 standard (hereafter referred to as AV protocol) for 
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transferring digital audio signals and digital video signals or transmitting data between 
devices coupled to an IEEE 1394 bus, employing the data transfer method conforming to 
the IEEE 1394 standard. In the AV protocol, video and audio data is located in the 
isochronous packet as shown in Fig. 5 and transferred. The isochronous packet includes a 
CIP (Common Isochronous Packet) header. The CIP header carries information that 
includes the type of AV data, the identification number of the device which is sending the 
isochronous packet, and the like. 

Fig. 5 shows the format of the isochronous packet used in the AV protocol. 
The isochronous packet comprises an isochronous packet header 900, header CRC 901, 
isochronous payload 902, and data CRC 903. The isochronous packet header 900 contains 
a tag 907. The tag 907 shows that the isochronous packet conforms to the AV protocol 
when its value is 1. When the value of the tag 907 is 1, which means that the isochronous 
packet conforms to the AV protocol, the isochronous payload 902 has a CIP header 904 at 
its beginning. The CIP header 904 comprises a source ID 906 which identifies the device 
transmitting the isochronous packet. The CIP header 904 also comprises FMT 908 and 
FDF 909 which specify the type of actual data 905 in the isochronous payload 902. 
Digital AV data is contained in the actual data 905, but the actual data 905 is not always 
contained in the isochronous payload 902. Some packets may have an isochronous 
payload 902 which contains only the CIP header 904 without the actual data 905. 

There is a group of commands called the AV/C Command Set for 
controlling devices in accordance with the AV protocol (Reference: 1394 TRADE 
ASSOCIATION Specification for AV/C Digital Interface Command Set Version 1.0, 
September 13, 1996). These commands and their responses are transferred by means of 
asynchronous communication. 

In the conventional data transfer method as described above, compatibility 
with conventional devices which are not designed for transferring an encrypted 
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isochronous payload 902 cannot be secured when an encrypted isochronous packet, which 
contains the isochronous payload 902 which has been encrypted for copy protection, is 
sent. More specifically, conventional devices are designed with the precondition that the 
CIP header 904 is normally positioned at the beginning of the isochronous payload 902. 
Accordingly, if the isochronous payload 902 is encrypted, conventional devices cannot 
correctly read out the encrypted CIP header 904, and decide that the isochronous packet 
does not conform to the AV protocol. A device receiving encrypted isochronous packets 
thus may not operate properly. In other words, such receiving devices cannot determine 
the type of data contained in the actual data 905, resulting in an inability to identify the 
device transmitting the isochronous packet. In addition, asynchronous communication 
such as queries to the sending device are disabled. Accordingly, normal receiving 
operations cannot be carried out. 

Furthermore, if the isochronous packet output from the sending device is 
encrypted while the receiving device is receiving the data, some conventional devices 
may not be able to correctly read out the CIP header 904 as soon as encryption starts, 
resulting in inability to receive data properly. 

In order to send AV information encrypted for copy protection from the 
sending device and decrypt the encrypted AV data by the authorized receiving device, the 
sending device needs to give decrypting information to the authorized receiving device. In 
the conventional data transfer method, however, the sending device may be required to 
execute extremely complicated procedures in order to specify the receiving device. More 
specifically, each isochronous packet contains the source ID 906 which is the identifier of 
the sending device, but these packets do not contain information that identifies which 
device is authorized to receive these packets. The sending device thus cannot check which 
device is receiving the isochronous packets during transmission of the isochronous 
packets. In order to find which of the devices coupled to the IEEE 1394 bus is receiving 
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the data, the sending device may require to query the data receiving status of every device 
coupled to the same bus. This makes the procedures for giving key information for 
decryption extremely complicated. 

5 SUMMARY OF THE INVENTION 

A data transfer method of the present invention satisfies the conventional 
communication standard even in the case of sending encrypted video and audio 
information via isochronous communication. In addition, the present invention offers a 
data transfer method which prevents erroneous operation even if conventional receiving 

1 0 devices receive isochronous packets containing encrypted video and audio data. 

The present invention still further offers a data transfer method which 
significantly simplifies procedures for giving key information for decryption from a 
sending device to an authorized receiving device. 

In a data transfer method of the present invention, synchronous data 

15 transferred via isochronous communication contains i) encryption identification 
information which indicates encryption status of actual data and ii) actual data, and only 
the actual data is encrypted. 

To solve another problem in the conventional data transfer method, the 
encryption identification information which indicates encryption status of the actual data 

2 0 in the synchronous data is sent together with the actual data from the sending device so 
that receiving device can detect that the actual data is encrypted based on this encryption 
identification information and request decrypting information to the sending device in the 
data transfer method of the present invention. Then, the receiving device receiving the 
decrypting information sent from the sending device upon request decrypts the actual data 

2 5 using this decrypting information to complete data transfer. 
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Also in the data transfer method of the present invention, the receiving 
device receiving synchronous data checks for the encryption identification information 
contained in the synchronous data. If the receiving device detects that the actual data is 
encrypted, the receiving device requests for decrypting information for decrypting the 
5 actual data to the sending device. This request is made using a command in the AV/C set 
via asynchronous communication. At receiving this request, the sending device checks the 
packet header of received command to identify the device making the request, i.e., the 
receiving device. The sending device then gives decrypting information to the identified 
receiving device using a command via asynchronous communication, enabling to realize 

fl 10 the data transfer method with extremely simple procedures for giving decrypting 

J information from the sending device to receiving device. 

I H Moreover, in the data transfer method of the present invention, only the 

7#k actual data in the synchronous data is encrypted, and the encryption identification 

J* information indicating the encryption status of the actual data is included in the 

^ 15 synchronous data. This enables to transfer the CIP header without being encrypted, 
jhs preventing erroneous operation when the conventional device receives such encrypted 

1;; synchronous data. In other words, the present invention realizes a data transfer method 

which assures compatibility with the conventional data transfer method and eliminates the 
possibility of erroneous operation when the conventional receiving device receives 
2 0 encrypted synchronous data. 

Furthermore, the data transfer method of the present invention eliminates the 
possibility of erroneous operation of the receiving device receiving data when encryption 
of synchronous data starts while continuously receiving synchronous data from the 
sending device because the CIP header is not encrypted and transferred as it is. 

25 



BRIEF DESCRIPTION OF THE DRAWING 
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Fig. 1 is a schematic view of a format of a CIP header in accordance with a 
preferred embodiment of the present invention. 

Fig. 2 is a block diagram illustrating functions of sending and receiving 
devices in accordance with the preferred embodiment of the present invention. 

Fig. 3A is a format of AKE status command in accordance with the 
preferred embodiment of the present invention. 

Fig. 3B is a format of AKE response to the AKE status command in 
accordance with the preferred embodiment of the present invention. 

Fig. 3C is a format of AKE control command in accordance with the 
preferred embodiment of the present invention. 

Fig. 4 is a schematic view illustrating procedures for transmitting an 
asynchronous packet between sending and receiving devices in accordance with the 
preferred embodiment of the present invention. 

Fig. 5 is a format of isochronous packet in a data transfer method of the 

prior art. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

A preferred embodiment of the present invention is described next with 
reference to drawings. 

Fig. 1 shows a format of the payload of an isochronous packet to be 
transferred in the preferred embodiment of the present invention. The preferred 
embodiment is one example of the transfer of a TSP (Transport Packet) in accordance 
with MPEG (the Moving Picture Expert Group) specifications. The ENC (hereafter 
referred to as encryption status) 910 indicates whether the actual data 905 is encrypted or 
not. 
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Fig. 2 shows the relation between sending and receiving devices in the 
preferred embodiment of the present invention. A sending device 110 and receiving 
device 128 are coupled via an IEEE 1394 bus (hereafter referred to as a 1394 bus) 111. 

First, the functions of each block in the sending device 1 10 are described. 
5 A signal source 100 outputs an MPEG transport packet TSP (not illustrated) 

in an 188 byte unit, which will be sent via the 1394 bus 1 1 1, to an encrypter 101. In other 
words, in the preferred embodiment, the signal source 100 outputs data with a fixed 
length of 188 bytes. The encrypter 101 encrypts and outputs the TSP received from the 
signal source 100 using an encryption key 109 provided by a key generator 106. In the 

10 preferred embodiment, the encryption key is equivalent to the decrypting information. An 
output command 105 is a command from the key generator 106 to the encrypter 101. 
There are three types of commands: normal output, encrypted output, and empty output. If 
the encrypter 101 receives the output command 105 for normal output, the TSP received 
from the signal source 100 is output without modification, and registers the value 0 as the 

15 encrypting information 910. If the output command 105 is for encrypted output, the 
encrypter 101 encrypts the TSP with the encryption key 109 received from the key 
generator 106, and registers the value 1 as the encrypting information 910. If the output 
command 105 is for empty output, the encrypter 101 outputs an empty signal (not 
illustrated) every time it receives a TSP from the signal source 100, and registers the 

20 value 1 as the encrypting information 910. A source packet generator 102 adds a 4-byte 
source packet header to the 18 8-byte TSP received from the encrypter 101, and outputs a 
192-byte source packet (actual data 905). A CIP block generator 103 adds a CIP header 
954 to the source packet received from the source packet generator 102, and outputs an 
isochronous payload 952. Here, the CIP block generator 103 places the encrypting 

25 information 910 received from the encrypter 101 in the CIP header 954. An isochronous 
packet generator 107 adds an isochronous packet header 900, header CRC 901, and data 
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CRC 903 to the isochronous payload 952 received from the CIP block generator 103, and 
outputs an isochronous packet. Since the content of the isochronous payload 952 is data 
that conforms to the AV protocol, the value of the tag 907 is set to 1. The key generator 
106 sends the encryption key 109 to the receiving device 128 by communicating the 
5 asynchronous packet with the receiving device 128, as shown in Fig. 3, which is described 
later. The key generator 106 also outputs the encryption key 109 to the encrypter 101 as 
described above. 

A 1394 packet I/O means 108 inputs and outputs isochronous and 
asynchronous packets between the 1394 bus 111 and sending device 110. More 

10 specifically, the 1394 packet I/O means 108 outputs the isochronous packet received from 
the isochronous packet generator 107 and asynchronous packet received from the key 
generator 106 to the 1394 bus 111, and also outputs asynchronous packet received from 
the 1394 bus 1 1 1 to the key generator 106. 

Next, functions of each block of the receiving device 128 are described. 

15 A 1394 packet I/O means 127 inputs and outputs isochronous and 

asynchronous packets between the 1394 bus 111 and receiving device 128. More 
specifically, the 1394 packet I/O means 127 outputs the isochronous packet received from 
the 1394 bus 111 to a payload extractor 123, and outputs asynchronous packet received 
from the 1394 bus 111 to a key generator 125. The 1394 packet I/O means 127 also 

2 0 outputs asynchronous packet received from the key generator 125 to the 1394 bus 111. 

The payload extractor 123 receives the isochronous packet, transmitted from 
the 1394 bus 111, from the 1394 packet I/O means 127. When the value of the 
isochronous packet tag 907 is 1, the payload extractor 123 determines that an isochronous 
payload 952 contains data conforming to the AV protocol, and outputs the isochronous 

25 payload 952 to an actual data extractor 122. When received isochronous payload 952 
contains the actual data 905, the actual data extractor 122 outputs the actual data 905 to a 
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decrypter 121 , after removing the CIP header 954 placed at the beginning of the 
isochronous payload 952. The actual data extractor 122 also outputs the source ID 906 
and encrypting information 910 extracted from the CIP header 954 to the key generator 
125. The encrypting information 910 is also output to the decrypter 121. The key 
5 generator 125 receives an encryption key 126 as a result of exchanging asynchronous 
packet with the sending device 110 via asynchronous communication, which is described 
later, and outputs the encryption key 126 to the decrypter 121. When the value of the 
encrypting information 910 received from the actual data extractor 122 is 0, the decrypter 
121 outputs the actual data 905 received from the actual data extractor 122 to an AV 

10 generator 120 as it is. When the value of the encrypting information 910 is 1, the 
decrypter 121 decrypts the actual data 905 using the encryption key 126 received from the 
key generator 125, and outputs decrypted actual data 905 to the AV generator 120. 

Next, the transmission of an asynchronous packet via the aforementioned 
asynchronous communication setup is described. 

15 Figs. 3 A to 3 C illustrate how the format of the asynchronous packet is 

transmitted by asynchronous communication. More specifically, Figs. 3A and 3C show 
the command formats of the AKE commands (AKE: Authentication and Key Exchange) 
communicated between the key generators 106 and 125. Fig. 3B shows the response 
format. These commands and responses belong to the AV/C Command Set, and are 

20 communicated between the sending device 110 and receiving device 128 using the 
asynchronous communication. By communicating these commands and responses, the 
sending device 110 and receiving device 128 exchange information required for the 
authentication of each other and encryption keys 109 and 126. The AKE commands 
comprise AKE control commands for requesting a target device to carry out a specific 

25 operation, and an AKE status commands for querying the status and capabilities of the 
target device. 
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Fig. 3A shows the format of the AKE status command. In the AKE status 
command, an operation code 208 indicates that this command is an AKE command. The 
value of the algorithm ID 200 is set at 0, with other values reserved for future extension. 

Fig* 3B shows the format of responses to the AKE status commands. This is 
5 a response sent back from the device receiving the AKE status command to the device 
issuing the AKE status command. There are multiple procedures for exchanging 
information for mutual authentication and transmission of encryption keys 109 and 126 
between the sending device 110 and receiving device 128. In an algorithm field 201, the 
identifier for an information exchange procedure which the device returning an applicable 

10 response can execute is assigned in bits. In other words, the receiving device 128 
exchanges several commands and responses with the sending device 110 after an 
encrypted TSP is detected in line with the aforementioned procedures and before 
receiving the encryption keys 109 and 126. There is more than one procedure for 
communicating these commands and responses. The device sending back the response 

15 designates the executable information exchange procedure by setting 1 to an applicable bit 
in the algorithm field 201. Since the size of the algorithm field 201 is 16 bits, a maximum 
of 16 types of information exchange procedures can be indicated. The maximum data 
length 212 indicates the longest receivable data length in the form of bytes for exchanging 
AKE commands and responses. 

20 Fig. 3C shows the format of the AKE control commands. The algorithm 

field 201 in the AKE control commands set informs of an executed information exchange 
procedure when the value of the algorithm ID 200 is 0. Only one bit in the algorithm field 
201 of the AKE control command and the response to AKE control commands is set at 1, 
and the other bits are 0. A bit having the value 1 indicates the information exchange 

2 5 procedure being used. A label 202 is used for identifying correspondence between AKE 
control commands. For example, let's say a certain information exchange procedure 
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specifies that the device receiving an AKE control command needs to return a different 
AKE control command corresponding to the AKE control command received when the 
AKE control command is sent from one device to another. In this case, the label 202 
inserted in the returned AKE control command will have the same value as the label 202 
5 inserted in the first AKE control command received, in order to clarify the correlation 
between both AKE control commands. In step No, 203, a serial number from 1 is given to 
each AKE control command in the sequence of communication in the information 
exchange procedure. 

A subfunction 299 takes the values shown in Table 1, and the meaning of 
1 0 each AKE command is determined by these values. 



Table 1 



Subfunction 


Value 


Make-response 


0016 


Verify-me 


0116 


Create-key- 


1016 


lnformation R econ struct-key 


1116 


Exchange 


2016 



If the subfunction 299 is the make-response, this AKE control command 
15 challenges the authentication of the device receiving this command. Here, the data 207 
contains authentication challenge data expressed as random numbers to authenticate the 
receiving device. The device receiving this command returns an AKE control command 
whose subfunction 299 is set to verify-me. 

When returning the AKE control command, the data stored in the data 207 is 
2 0 the authentication response data which is a result of a predetermined operation with 
respect to the authentication challenge data in the received data 207. The key information 
used for this operation is a key given only to an authorized device in advance. Whether 
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the device executing the operation is an authorized device or not can be determined by 
checking the returned authentication response data. 

If the subfunction 299 is the create-key-information, this AKE control 
command requests the encryption key 109 to the device receiving this command. The 
5 device receiving this AKE control command returns the AKE control command whose 
subfunction 299 is set to reconstruct-key. At this point, the encrypted encryption key 109 
is stored in the data 207 and returned. 

If the subfunction 299 is the exchange, this AKE control command requests 
the exchange of key information between devices sending and receiving the command. 

1 0 This key information is stored in the data 207 and transferred for indirect authentication 
between devices or the creation of a common key. 

Values other than those specified in Table 1 are reserved for future 
extension. The channel No. 204 indicates the channel number for isochronous 
communication between the sending device 110 and receiving device 128. This channel 

15 No. 204 is valid only when the subfunction 299 is set to the create-key-information or 
reconstruct-key. In other cases, this value will be set to FF in hexadecimal format. Block 
No. 205 and total block No. 206 are used when data which should be handled by the AKE 
control command cannot be sent by one AKE command. In this case, applicable data is 
divided into blocks, and transferred in several transmissions. The total block No. 206 

2 0 indicates the number of divided blocks in applicable data. The block No. 205 indicates the 
number of each block in the data 207. The data length 209 indicates the valid data length, 
as bytes, in the data 207. The data 207 is data exchanged by the AKE control command. 
The device receiving the AKE control command returns a response to that specific AKE 
control command. The format and value of the response are the same as those of the 

25 received AKE control command. The only detail which differs is that the response does 
not contain the data 207. 
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Fig. 4 shows a chronological example of AV/C commands which are 
exchanged between the sending device 110 and receiving device 128 before sending the 
encryption keys 109 and 126 from the sending device 1 10 to receiving device 128. First, 
operations of both devices before exchanging AV/C commands shown in Fig. 4 are 
5 briefly described. 

An initial condition is that non-encrypted TSP is sent from the sending 
device 110. The TSP output from the signal source 100 is input to the encrypter 101. 
Since the output command 105 is set to the normal output, the encrypter outputs TSP as it 
is without encryption to the source packet generator 102, and registers the value 0 as the 

10 encrypting information 910. The source packet generator 102 adds 4-byte source packet 
header to the TSP received, and outputs it to the CIP block generator 103. The CIP block 
generator 103 adds 8-byte CIP header 954, and outputs it as isochronous payload 952 to 
the isochronous packet generator 107. Here, the encrypting information 910 contained in 
the CIP header 954 is 0 which is input from the encrypter 101. The isochronous packet 

15 generator adds the isochronous packet header 900, header CRC 901, and data CRC 903 to 
the received isochronous payload 952 to create the isochronous packet. This isochronous 
packet is output to the 1394 bus 111 by the 1394 packet I/O means 108. Since the 
applicable isochronous packet conforms to the AV protocol, the tag 907 in the 
isochronous packet header 900 is set to 1. 

2 0 When the TSP output from the signal source 100 is changed, which means 

that AV information changes from that unprotected AV information to copy-protected AV 
information, the key generator 106 detects this change, and changes the output command 
105 from the normal output to empty output. At the same time, the encryption key 109 for 
encrypting TSP is given to the encrypter 101. 

25 When the output command 105 is for empty output, the encrypter 101 

outputs an empty signal to the source packet generator 102 every time it receives a TSP 
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from the signal source 100, and registers the value 1 as the encrypting information. At 
receiving the empty signal from the encrypter 101, the source packet generator 102 
transmits the received empty signal as it is to the CIP block generator 103 without adding 
the source packet header. When the CIP block generator 103 receives the empty signal, it 
5 outputs only the CIP header 954 to the isochronous packet generator 107. Here, the 
encrypting information 910 in the CIP header 954 uses the value 1 output from the 
encrypter 101. The isochronous packet generator 107 creates an isochronous packet as the 
isochronous payload 952 using the CIP header 954 received from the CIP block generator, 
and outputs it to the 1394 packet I/O means 108. Since this isochronous packet conforms 

10 to the AV protocol, the value of the tag 907 is set to 1. The 1394 packet I/O means 108 
outputs received isochronous packet to the 1394 bus 111. This isochronous packet is 
continuously output, and the isochronous packet only containing the CIP header 954 in 
this isochronous payload 952 is continuously output to the 1394 bus 111. The receiving 
device 128 receiving this isochronous packet checks its tag 907 by the 1394 packet I/O 

15 means 127, detects that the isochronous packet conforms to the AV protocol, and then 
outputs this isochronous packet to the payload extractor 123. The payload extractor 123 
extracts the isochronous payload 952 from received isochronous packet, and outputs it to 
the actual data extractor 122. The actual data extractor 122 outputs the encrypting 
information 910 and source ID 906 in the CIP header 954 to the key generator 125. After 

2 0 the key generator 125 detects that the value of the encrypting information 910 is 1, the 
receiving device 128 learns that device outputting the isochronous packet from the source 
ID 906 is the sending device 110. Then, the key generator 125 finally goes onto a process 
for requesting the encryption keys 109 and 126 using the A/C commands, as shown in 
Fig. 4. 

25 In Fig. 4, the AKE status command 300 is first sent from the receiving 

device 128 to sending device 110. This enables the receiving device 128 to query 
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information exchange procedure that can be used by the sending device 110. Replying to 
this query, the sending device 110 returns the AKE response 301 to the receiving device 
128. Information exchange procedure which the sending device 110 can execute is 
assigned in bits in the algorithm field 201 of the AKE response 301. This allows the 
receiving device 128 to learn which information exchange procedures can be executed by 
the sending device. For example, if the sending device 110 can execute the second and 
sixth information exchange procedures, binary indication in the algorithm field 201 of the 
AKE response 301 will be 0000000000100010. 

The receiving device 128 receiving the AKE response 301 selects one 
optimal procedure from information exchange procedures that both sending device 110 
and receiving device can execute. Then, AV/C commands are exchanged according to the 
selected exchange procedure. Let's say the receiving device 128 can execute the second 
and eighth information exchange procedures. Then, the information exchange procedure 
which can be executed by both sending device 110 and receiving device 128 is only the 
second procedure. Accordingly, the rest of authentication and information exchange are 
executed using the second procedure. In the AKE control command in this procedure, the 
value of algorithm ID will be 0 and the value of the algorithm field 201 will be 
0000000000000010 in hexadecimal indication. The information exchange procedure 
specifies not only the sequence of exchanging a range of AKE control commands but also 
a format and processing method of the data 207 sent by each AKE control command. 

In accordance with the second information exchange procedure, the key 
generator 125 sends the make response command 302 to the sending device 110. In the 
data 207 of this make response command 302, two random numbers RRa and RRb 
generated by the key generator 125 are encrypted, and the algorithm field 201 contains 
identification information indicating the use of the second procedure. The key used for 
encryption is a common secret key given to both authorized sending device and receiving 
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device in advance. The key generator 106 receiving the make-response command 302 
checks the algorithm field 201 of the received make-response command 302, and learns to 
use the second procedure for the rest of authentication and information exchange. Since 
the key generator 106 can execute the second procedure, the key generator 106 knows that 
5 the data 207 of the make response command 302 sent in accordance with this second 
procedure contains two random numbers encrypted by this secret key. After taking out 
two random numbers RRa and RRb from the data 207 using this secret key, the key 
generator 106 returns a response 303 to inform that a response can be generated. Then, the 
key generator 106 stores one of the random numbers RRa taken out in the data 207, and 

10 sends the verify-me command 304 to the receiving device 128. This is the response 
requested by the previous make-response command 302. Hereafter, the algorithm field 
201 of each AKE command exchanged between the sending device 110 and receiving 
device 128 always contain the identification information indicating the second procedure. 

The key generator 125 receiving the verify-me command 304 confirms that 

15 RRa in the data 207 conforms to the random number RRa generated by itself, and then 
returns a response 305 to the verify-me command 304 to inform that verification has 
completed successfully. The key generator 125 then finally authenticates that the sending 
device 1 10 is an authorized sending device. 

The sending device 110 then use the make-response command 306 and 

20 verify-me command 308 in accordance with the procedures after the make-response 
command 302 described above to confirm that the receiving device 128 is an authorized 
receiving device. However, the random number used here is RTa and RTb, and the 
random number sent back by the verify-me command 308 is RTb. 

Now that both sending device 110 and receiving device 128 know the 

2 5 random numbers RRb and RTb, and have confirmed that both are authorized devices, the 
key generator 106 and key generator 125 separately generates a temporary key (not 
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illustrated) from RRb and RTb using a common operation method specified by the second 
procedure. These temporary keys are a common key only between the sending device 110 
and receiving device 128. 

Next, the key generator 125 sends the create-key-information command 310 
5 to the sending device 1 10. A channel number of the isochronous packet that the receiving 
device 128 is currently receiving is stored in the channel No. 204 of the create-key- 
information command 310. The key generator 106 receiving this create-key-information 
command 310 encrypts the encryption key 109 to be used for encrypting TSP with the 
aforementioned temporary key, and then returns a response 3 1 1 to inform that the create- 

10 key-information command 310 has completed successfully. Then, the key generator 106 
sends the reconstruct-key command 312 which stores the encryption key 109 encrypted 
by the temporary key in its data 207 to the receiving device 128. The key generator 125 
uses the temporary key to decrypt the data 207 of the reconstruct-key command 312 
received, and obtains the encryption key 126. Then, the key generator 125 returns a 

15 response 313 to inform that the reconstruct-key command 312 has completed 
successfully. Since the encryption keys 109 and 126 are encrypted and decrypted using 
the same temporary key, they are the same keys. The encryption key 126 is output from 
the key generator 125 to the decrypter 121. This completes the procedure for granting 
decrypting information. 

2 0 The key generator 106 which has sent the reconstruct key command 312 

outputs the output command 105 for encrypted output to the encrypter 101. The encrypter 
101 receiving this command encrypts TSP received from the signal source 100 by the 
encryption key 109, and starts to output it to the source packet generator 102. This enables 
the sending device 110 to send the isochronous packet containing TSP encrypted by the 

2 5 encryption key 109 in its isochronous payload 952 on the 1349 bus 1 1 1 . This isochronous 
packet received by the receiving device 128 is decrypted by the decrypter using the 
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encryption key 126 as described above, and outputs the decrypted packet to the AV 
generator 120. 

In the above series of AKE control commands, each set of the make 
response command 302 and verify-me command 304; make-response command 306 and 
verify-me command 308; and create-key-information command 310 and reconstruct-key 
command 312, respectively has the same label 202. The make-response command 302, 
verify me command 308, create-key-information command 310, and reconstruct key 
command 3 12 also have values 1 , 2, 3, 4, 5, and 6 in the step No. 203 respectively. 

If the actual data 105 in the isochronous packet output from the sending 
device 110 changes from encrypted actual data 105 to non-encrypted actual data 105, the 
decrypter 121 detects the change in the encrypting information 910, stops decryption, and 
outputs the data received from the actual data extractor 122 as it is to the AV generator 
120. 

If a bus reset occurs in the 1394 bus 1 1 1 after the aforementioned processes 
shown in Fig. 4 starts, the procedures after and make-response command 302 need to be 
repeated. 

As described above, in the preferred embodiment of the present invention, 
the sending device sends encrypting information which indicates the encryption status of 
the actual data in the isochronous packet together with the actual data. This enables the 
receiving device receiving the isochronous packet to make a request to the sending device 
for an encryption key for decrypting the actual data if the receiving device detects, by 
checking the encrypting information in the isochronous packet, that the data is encrypted. 
The sending device receiving the request then gives the encryption key to the receiving 
device. Accordingly, the data transfer method of the present invention offers extremely 
simple procedures for giving the encryption key from the sending device to receiving 
device for decryption. 
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Moreover, in the preferred embodiment of the present invention, the 
isochronous packet transferred via isochronous communication contains i) encrypting 
information indicating the encryption status of the actual data and ii) actual data, but only 
the actual data is encrypted for data transfer. This makes possible a data transfer method 
5 which has no risk of erroneous operation when a conventional receiving device receives 
encrypted actual data while maintaining compatibility with the conventional data transfer 
method. 

Furthermore, in the preferred embodiment of the present invention, the CIP 
header remains non-encrypted for transfer even if encryption of synchronous data starts 

1 0 while the receiving device is continuously receiving synchronous data sent by the sending 
device. This enables a data transfer method which eliminates the possibility of erroneous 
operation of the receiving device receiving the data. 

In the preferred embodiment, once encryption by the encryption key starts, 
actual data in all transfer units is encrypted and sent. However, it is not necessary to 

15 encrypt all units of data to be transferred. For example, even if both encrypted transfer 
units and non-encrypted transfer units are sent alternately, the receiving device can 
correctly decrypt the data because encrypting information is included in the CIP header, 
thus achieving the same effect. In addition, it is apparent that the same effect is also 
achievable even if the receiving device specifies a percentage of encrypted transfer units 

20 to the sending device. The size of the MPEG source packet is 1 92 bytes, with more than 
one source packet stored in one isochronous payload in the case of the high data rate 
transfer of MPEG (12 Mbps minimum). Naturally, however, it is not possible to have both 
encrypted source packet and non-encrypted source packet in the same isochronous 
payload. 

25 In the preferred embodiment, all actual data is encrypted using the 

encryption key. However, it is not necessary to encrypt all pieces of data. For example, 
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the same effect is achievable by encrypting the first half of the actual data, or encrypting 
the first and third quarters of the actual data. In this case, the receiving device can decrypt 
appropriately, if, when sending the data, information is inserted to indicate encrypted 
portions and their percentage in the CIP header. The same effect is also achievable by 
inserting in the CIP header encrypting information announcing whether the actual data is 
encrypted or not. The receiving device queries the sending device via asynchronous 
communication about which part of the actual data is encrypted and to what level, when 
the receiving device detects encryption by checking the CIP header. The same effect is 
also achievable in this case even when the receiving device specifies the encryption area 
and percentage to the sending device via asynchronous communication. If only the 
confidential portion in the actual data is encrypted, the burden for encryption and 
decryption is reduced, and at the same time, a sufficient effect of encryption may be 
achieved. 

In the preferred embodiment, the isochronous packet containing only the 
CIP header without actual data is transferred until the completion of mutual authentication 
between the sending and receiving devices. However, the same effect is achievable even 
when an isochronous packet containing encrypted actual data is output from the start, and 
not the isochronous packet containing only the CIP header. 

In the preferred embodiment, procedures for transferring the AKE control 
commands between sending and receiving devices are determined by mutual negotiation. 
However, if the receiving device features only one executable procedure, the same effect 
is achievable by starting to transfer commands immediately, without executing this 
negotiation procedure, using only the executable procedure. In this case, it may be 
preferable to specify in advance a basic minimum of executable procedures for all 
authorized devices. 
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In this preferred embodiment, direct authentication is implemented between 
the sending and receiving devices, following which decrypting information is transferred 
using a secret key. However, the means for transferring authentication and decrypting 
information is not limited to this procedure. For example, a public key may be used for 
mutual indirect authentication and the creation of a temporary key. Decrypting 
information may then be transmitted using this temporary key. Such procedures are 

briefly described below. 

The sending and receiving device stores the key information necessary for 
mutual indirect authentication in the data 207 of the AKE control commands, and send 
this information to each other in line with a procedure determined by mutual negotiation. 
Here, the subfunction 299 is set to the exchange. This enables both sending and receiving 
devices to share the same temporary key if they are both authorized devices. Decrypting 
information is then transferred using the create-key-information command and 
reconstruct-key command in accordance with the same procedures as those described in 
the preferred embodiment. 

In the preferred embodiment, the procedure for transferring AKE control 
commands exchanged between sending and receiving devices is determined by mutual 
negotiation. If the types of procedures executable by the sending device are known in 
advance, the same effect is achievable by having the receiving device transfer commands 
using a procedure executable by the sending device without first executing this 

negotiation procedure. 

In the preferred embodiment, procedures for transferring AKE control 
commands exchanged between sending and receiving devices are determined by mutual 
negotiation. However, the method for determining transfer procedures is not limited to 
this one. More specifically, if priority is given in advance to each of several transfer 
procedures, the receiving device may start to transfer using the procedure given the 
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highest priority which is executable by itself. If the sending device cannot execute that 
procedure, the receiving device tries to transfer data by going down the list of procedures 
in order of priority until a procedure that is executable by both the sending and receiving 
device is found. The AKE control commands are then transferred using this procedure to 
5 achieve the same effect. 

In the preferred embodiment, the sending device encrypts decrypting 
information which is used for decrypting actual data before transferring it to the receiving 
device. However, the way the receiving device obtains decrypting information is not 
limited to this procedure. In other words, the sending device may provide the receiving 

10 device sufficient information for obtaining decrypting information, without transferring 
encrypted decrypting information, and the receiving device may obtain decrypting 
information indirectly from this information. More specifically, the sending device 
transfers only the type of hash function to the receiving device, and the receiving device 
obtains decrypting information using the received type of hash function to achieve the 

15 same effect. 

The preferred embodiment described above comprises an example of the 
AKE command format. However, the AKE command format is not limited to this one. In 
other words, the AKE command format indicated in this embodiment is just one example 
of how the preferred embodiment may be realized. The same effect is achievable by using 
2 0 commands in a different format. 

Industrial applicability 
As described above, the present invention has the significant effect of 
realizing a data transfer method using extremely simple procedures for passing key 
25 information from the sending device to the receiving device for decryption. Encryption 
identification information indicating the encryption status of actual data in synchronous 
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data is sent together with actual data. The receiving device receiving the synchronous data 
checks the encryption identification information in the synchronous data, and if it detects 
that the actual data is encrypted, the receiving device requests the sending device for 
decrypting information for decrypting the encrypted data. The sending device receiving 
5 this request gives the decrypting information to the receiving device. 

The present invention has another significant effect of realizing a data 
transfer method which eliminates the possibility of erroneous operation of the receiving 
device even if conventional receiving device receives encrypted synchronous data, while 
maintaining compatibility with a conventional data transfer method. Synchronous data 

10 transferred through synchronous communication contains i) encryption identification 
information indicating encryption status of the actual data and ii) actual data, but only the 
actual data is encrypted for data transfer. 

The present invention has still another significant effect of realizing a data 
transfer method which eliminates the possibility of erroneous operation of the receiving 

15 device even if encryption of synchronous data starts while the receiving device 
continuously receives synchronous data sent from the sending device. Synchronous data 
transferred through synchronous communication contains i) encryption identification 
information indicating encryption status of the actual data and ii) actual data, but only the 
actual data is encrypted for data transfer. This enables to transfer the CIP header as it is 

2 0 without being encrypted. 

The present invention has still another significant effect of realizing a data 
transfer method which always executes the most suitable procedure even when new and 
conventional devices share the same network. A procedure for both authentication and 
decrypting information with good future extendibility are achievable by selecting a 

25 procedure for providing authentication information and decrypting information exchanged 
between the sending and receiving devices by negotiation between the sending and 
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receiving devices. In other words, even if a new authentication method or decrypting 
information become available in the future, the most suitable procedure will remain 
selectable by negotiation between devices even if a device which can use the new 
procedure and a device which can use only conventional procedures share the same 
network, as long as the new device is back-compatible with older procedures. 

The present invention has still another significant effect of realizing 
decryption even if software which has a low encryption/decryption processing rate is 
used. The present invention allows the relative proportion of encrypted actual data and 
non-encrypted actual data to be varied within a single file. Accordingly, even if the 
receiving device has no exclusive hardware for high-speed data decryption, software can 
be used instead. More specifically, even if the receiving device has no hardware for 
decryption like PC, rapid processing is made possible by reducing the proportion of 
encrypted data in the file and thus shortening the time required for the decryption process. 

The present invention has still another significant effect of realizing a data 
transfer method which uses the limited bus transfer band efficiently and significantly 
reduces the risk of unauthorized device receiving readable data. Unless the sending and 
receiving devices mutually authenticate that both are authorized devices, isochronous 
packets without actual data are output. 



16229JlPCTEl.doc 1999/9/25 
What is claimed is: 



25 



1 1 . A method for transferring data on a bus system in which both isochronous 

2 communication and asynchronous communication are employed; said isochronous 

3 communication is for any device on the bus to receive synchronous data; said 

4 asynchronous communication is for a predetermined device to receive asynchronous data; 

5 said synchronous data may contain actual data; said synchronous data also contains 

6 encryption identification information at an area other than said actual data; said 



7 encryption identification information indicates the status of encryption of said actual data; 

8 and encrypted actual data is decrypted using decrypting information obtained through the 

9 following steps: 

10 a) a receiving device receiving said synchronous data makes a request for 

11 decrypting information of said actual data to a sending device sending said synchronous 

12 data via said asynchronous communication, if said encryption identification information 

1 3 indicates that said actual data is encrypted; 

14 b) said sending device receiving said request sends one of: 

15 i) encrypted decrypting information of said actual data; and 

16 ii) data required for obtaining said decrypting information 

17 to said receiving device via said asynchronous communication; and 

18 c) said receiving device executes one of: 

19 i) taking out said decrypting information from said encrypted decrypting 
2 0 information when said receiving device receives said encrypted decrypting information; 

21 and 

22 ii) obtaining said decrypting information using said data for obtaining 

23 said decrypting information when said receiving device receives said data for obtaining 
2 4 decrypting information. 
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1 2. The method for transferring data as defined in Claim 1, wherein a 

2 plurality of types of procedures are available between the steps of detecting encryption of 

3 said actual data and obtaining said decrypting information by said receiving device 

4 receiving said synchronous data; and said receiving device executes the next steps for 

5 obtaining said decrypting information before requesting said decrypting information: 

6 i) querying said sending device of types of procedures executable by said 

7 sending device; 

8 ii) selecting a procedure from those executable by both sending device and 

9 receiving device; and 

10 iii) obtaining said decrypting information in accordance with said selected 

11 procedure. 
12 

1 3. The method for transferring data as defined in Claim 2, wherein said 

2 procedure is selected in accordance with a predetermined priority when there are a 

3 plurality of procedures executable by both of said sending device and said receiving 

4 device. 
5 

1 4. The method for transferring data as defined in Claim 1 ? wherein a 

2 plurality of types of procedures are available between the steps of detecting encryption of 

3 said actual data and obtaining of said decrypting information by said receiving device 

4 receiving said synchronous data; and said receiving device executes the next steps for 

5 obtaining said decrypting information: 

6 i) starting said procedure selected from said plurality of types of procedures 

7 in accordance with a predetermined priority; 
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8 ii) re-selecting one of said procedures until said procedure executable by 

9 said sending device is found when the procedure selected by said receiving device is not 

1 0 executable by said sending device; and 

11 iii) obtaining said decrypting information in accordance with the selected 

12 procedure when a procedure executable by said sending device is found. 

13 

1 5. The method for transferring data as defined in one of Claims 2 to 4, 

2 wherein said asynchronous data transmitted between said sending device and said 

3 receiving device in accordance with said selected procedure contains an identifier for 

4 indicating the type of said procedure executed. 
5 

1 6. The method for transferring data as defined in one of Claims 1 to 5, 

2 wherein said receiving device authenticates whether said sending device is an authorized 

3 sending device before making a request for said decrypting information. 
4 

1 7. The method for transferring data as defined in one of Claims 1 to 5, 

2 wherein said sending device receiving a request for said decrypting information 

3 authenticates that said receiving device is an authorized receiving device before sending 

4 encrypted decrypting information of said actual data after confirming. 

5 

1 8. The method for transferring data as defined in one of Claims 1 to 5, said 

2 sending device and said receiving device mutually authenticate that both are authorized 

3 sending device and receiving device before said receiving device makes a request for said 

4 decrypting information. 
5 
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1 9. The method for transferring data as defined in one of Claims 1 to 8 ? 

2 wherein the next steps are executed before said receiving device makes a request for said 

3 decrypting information: 

4 i) said receiving device sends information required by said sending device at 

5 least for creating a common key to said sending device; and 

6 ii) said sending device sends information required by said receiving device 

7 at least for creating said common key to said receiving device; 

8 and then said sending device encrypts decrypting information using said 

9 common key and sends said encrypted decrypting information; and said receiving device 

10 takes out said decrypting information from said encrypted decrypting information 

1 1 received using said common key. 
12 

1 10. The method for transferring data as defined in one of Claims 1 to 5, 

2 wherein only said actual data is encrypted. 
3 

1 11. The method for transferring data as defined in one of Claims 1 to 5, 

2 wherein said sending device has a signal source of said actual data inside and determines 

3 encryption of each of said actual data in a fixed length unit output from said signal source; 

4 and said sending device places encrypted actual data and non-encrypted actual data in 

5 different output units of said synchronous communication, and then outputs them to said 

6 bus system. 
7 

1 12. The method for transferring data as defined in Claim 11, wherein said 

2 receiving device specifies a percentage of said encrypted actual data and said non- 

3 encrypted actual data to said sending device using said asynchronous communication; and 
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4 said sending device changes the percentage of encryption in accordance with said 

5 specification. 
6 

1 13. The method for transferring data as defined in one of Claims 1 to 5, 

2 wherein said sending device has a signal source of said actual data inside, and determines 

3 a percentage of encryption of said actual data in a fixed length unit output from said 

4 signal source; and said sending device places said actual data in an output unit of said 

5 synchronous communication, and then outputs it to said bus system. 
6 

1 14. The method for transferring data as defined in Claim 13, wherein said 

2 receiving device specifies a percentage of said encryption to said sending device using 

3 said asynchronous communication, and said sending device changes the percentage of 

4 encryption in accordance with said specification. 

5 

1 15. The method for transferring data as defined in one of Claims 1 to 5, 

2 wherein said sending device sends said synchronous data excluding said actual data until 

3 at least said decrypting information is requested; and said sending device starts sending 

4 synchronous data containing said actual data only after at least receiving said request for 

5 said decrypting information. 
6 
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ABSTRACT OF THE DISCLOSURE 

A data transfer method which eliminates erroneous operation of conventional 
devices not supporting encryption when copy-protected AV information is encrypted and 
sent on the IEEE 1394 bus. Synchronous data transferred through isochronous 
communication contains i) encryption identification information for indicating encryption 
of actual data and ii) actual data. Only the actual data is encrypted. Encryption 
identification information indicating encryption status of actual data in synchronous data is 
sent together with actual data from the sending device. A receiving device detecting 
encryption of actual data from this encryption identification information requests for 
decrypting information to the sending device. The receiving device decrypts the actual data 
using decrypting information received from the sending device according to this request. 
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Christopher J. Dervishian Reg. No. 42,480 
Jack J. Jankovitz Reg. NcT^B^n* 



Address all correspondence to: Lawrence E. Ashery 

Ratner & Prestia, Suite ^J^^^^^^^^ P Q - Box 980 » Valle y For 9 e ' PA 19482-0980 
Affaressalile^^ at (610) 407-0700T~ 

I hereby declare that all statements made herein of my own knowledge are true and that all 
statements made on information and belief are believed to be true; and further that these statements 
were made with the knowledge that willful false statements and the like so made are punishable 
by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States Code and that 
such willful false statements may jeopardize the validity of the application or any patent issued thereon. 



Full name of sole or first inventor (given name, family name) Takuya Nishimura 



Inventor's si 



gnature K~^^t^J^ /^ f /^^ A >>i^^9i 



Date December 9 f 1999 



Residence Osaka, Japan ^S^p^f^ 
Citizenship Japanese 

Post Office Address 6-1-105, Myokenzaka, Katano-shi, Osaka 576-0021 Japan 




Full name of second joint inventor, if any (given name, family name) Hiroyuki litsuka 

Second Inventor's signature ((^A^fS^ 
Residence Osaka, Japan ~TN^ 
Citizenship Japanese 

Post Office Address 6-25-6, Kisaichi, Katano-shi, Osaka, 576-0033 Japan 



Date December 9, 1999 



Additional inventors are being named on separately numbered sheets attached hereto. 
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Full n*™* nf thirH joint inventor, if any faiven name, family name) Masazumi Yamada 




Third inventor's sianature /^^ftZfttffof fyfavJid ^n— - 
Residence Osaka, Japan U 
Citizenship Japanese 

Post Office Address 6-24-10, Kinda-cho, Moriguchi-shi, Osaka 570-0011 Japan 

— 


Date December 9, 1999 


Full name of fourth joint inventor, if any (given name, family name) 




Fni irth inventor's siqnature 

Residence 

Citizenship 

Post Office Address 


Date 


Full name of fifth joint inventor, if any (given name, family name) 

^ ; Fifth inventor's signature _ 

^Residence 

- Citizenship 

• Post Office Address 


Date 


Full name of sixth joint inventor, if any (given name, family name) 




Sivth inventor's sianature 

0 Residence 

'I Citizenship 

^ Post Office Address 


Date 


Full name of seventh joint inventor, if any (given name, family name) 




Seventh inventor's sianature 

Residence 

Citizenship 

Post Office Address 


Date 
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